Skip to content

Interfaces that admit they are guessing

May 2026 6 min read

Optimistic updates are the closest thing interface work has to a magic trick. You click, the row appears, the number goes up, and the request has not left the building. It feels instant because it is a lie told confidently, and told well it is the right lie: most requests succeed, so most of the time the interface simply told you the future a few hundred milliseconds early.

The trouble is what happens on the other few percent, and how rarely anyone designs it.

The shape of the failure

The default failure is silent reversal. The row you added quietly disappears. The toggle you flipped flips back. Nothing announces itself, because the code path that handles the error is the one nobody could think of a design for, so it rolls back the state and hopes.

To the person using the software, this does not read as a network failure. It reads as: I did something wrong, or this application is haunted. Both conclusions cost you more trust than a spinner ever would have.

Say what you know

The honest version is not complicated. An interface that has made a guess should show that it is guessing, and it should be specific about what it will do when it finds out.

  • Pending work looks pending — dimmed, not absent
  • A failure names the operation, not the layer it failed in
  • Whatever the person typed survives the failure
  • Retrying is one action, and it is right there

That last one is the whole thing. A failure with no recovery in reach is just bad news. A failure with a retry button attached is an inconvenience, and inconveniences are survivable.

The number nobody wants

Ask a team what their optimistic mutation failure rate is and you will usually get a shrug, then a guess, then — if you wait — the admission that it is not measured, because the rollback path does not log anything. The interface swallowed it. The dashboard is clean because the failure never made it out of the browser.

If your error rate looks perfect, check whether you are counting the errors your interface handled by pretending.

I have never once instrumented that path and found the number I expected. It is always higher, and it is always concentrated in a handful of accounts on bad connections who have simply learned that the software does not work for them.

Confidence is a design material

None of this is an argument against optimism. Waiting for the server before you acknowledge a click is its own kind of dishonesty — it pretends the outcome is uncertain when it is not.

The useful frame is that certainty is a spectrum and the interface should sit at the right point on it. Sure things happen instantly. Likely things happen instantly and carry a quiet mark that they are not settled. Genuinely uncertain things wait, and say why.

Get the mapping right and the software feels fast and trustworthy at the same time, which most people assume is a trade-off. It is not. It is just work nobody assigned.

More writing